The Metro Ethernet Forum (MEF) develops technical specifications and implementation agreements to promote interoperability and deployment of Carrier Ethernet worldwide. MEF Technical Specification 6.1 defines a particular Ethernet service type called Ethernet-Tree (or E-Tree), which is based on a Rooted-Multipoint Ethernet Virtual Connection (EVC). In a simple form, an E-Tree Service type is a point to multi-point service over Ethernet technology and may provide a single root for multiple leaf user network interfaces (UNIs) or nodes. Each leaf UNI can exchange data with only the root UNI. E-Tree service may be useful for Internet access or video-over-IP applications, such as multicast/broadcast packet video.
A P2MP (point to multi-point) has exactly one root and at least two leaves. In P2MP the root communicates with at least one leaf and further a leaf cannot communicate with any other leaf directly but may do so via the root if allowed by the operator. Each root is sourcing unicast or multicast traffic to the leaves. A leaf can only communicate with its root by sending unicast frames to the root. If a root fails then none of the leaf will receive any traffic. For providing resiliency in scenarios where failure of root is inevitable, additional roots are provided wherein leaf switches from one root to another root when the original root is not reachable. This resilient mechanism is called as Multi-rooted P2MP (MRP2MP).
In PBN (provider bridging network) MRP2MP is not possible because the edge nodes or equipments or Provider Edge Bridges (PEB) do not have feature of switching from one destination address to another destination address. PEBs can only forward the traffic to the next bridge; they cannot change the destination address of the Ethernet Frame. PBN can support only P2MP service. Further, for P2MP service, a PBN will need at least two VLAN IDs (see FIG. 2): one for traffic from leaves towards the root 1 and another for traffic from root 1 towards the leaves. In the FIG. 2, the VLAN ID (as shown) provisioning required in the provider bridge (PB) which is connecting root 1, leaf 1 and leaf 2. Sometimes this provider bridge is also called as BCB. The BCB has two mechanisms: one for tagging the incoming frame at the ingress port (this is represented by small squares attached to the outer square; the letters inside the small square are VLAN IDs as shown in FIG. 2) and one for forwarding the frame through the correct egress port (this is represented by small squares attached to the inner square; the letters inside the small square are VLAN IDs as shown in FIG. 2). When leaf 1 sends a frame, BCB will tag the frame with VLAN ID, say B, at the tagging square. After tagging, the frame enters the forwarding square. In the forwarding square frames tagged with VLAN ID B is configured to be forwarded towards root 1. Notice that tagging and forwarding is so configured that communication between leaves is prevented. When root 1 sends a frame, either unicast or multicast, BCB will tag the frame with VLAN ID, say R, at the tagging square. After tagging, the frame enters the forwarding square. In the forwarding square frames tagged with VLAN ID R is configured to be forwarded towards leaves. If unicast frame is to be forwarded then frame is forwarded towards the leaf matching the destination address in the frame. If multicast frame is to be forwarded then frame is forwarded towards both leaf 1 and leaf 2. Notice that tagging and forwarding is so configured that root 1 can send both unicast and multicast towards the leaf. As this tagging and forwarding is based on VLAN IDs, service failure resulting from failure of root 1 cannot be protected. Further, we need two VLAN IDs for P2MP to work. VLAN ID is a priced resource in networking and any mechanism targeted towards saving the VLAN is going to be very useful. Moreover, switching from one root to another root is not possible because PEB or any client device does not have method to change the destination address at layer 2.
In PBB (provider backbone bridging), the edge bridges are called as backbone edge bridge (BEB). In the FIG. 2 (as shown) three BEBs: root 1, leaf 1 and leaf 2. In PBB, a P2MP is provisioned as follows: Traffic entering the BEBs are marked with an ISID picked from a pool of P2MP ISID. ISID is 24 bit identifier that identifies service type. Traffic from leaf 1 and leaf 2 are given backbone destination address as root 1 and traffic from root 1 is given unicast backbone destination address of the leaves for unicast traffic and is given multicast backbone destination address derived from combination of OUI (organizationally unique identifier) and ISID for multicast traffic. The frames egressing from the BEB towards other BEBs within the PBB are further tagged with backbone VLAN ID (BVID). This BVID identifies the path taken by the P2MP within the PBB network. If a link along the path fails then the path restoration protocol will try to find another path to restore the P2MP service. Notice that each P2MP will be uniquely identified by a single ISID. We need only one BVID for many number of P2MP services. There are 16 million ISIDs and only 4096 VLAN IDs. Notice here we need only one backbone VLAN ID unlike in PBN where we needed two VLAN IDs per P2MP. Though we have saved the VLANs we cannot protect service failure from failure of root 1. PBB does not have a mechanism where leaves can switch to different root upon failure of original root.
In PBB-TE, the backbone edge bridges have capabilities in addition to that in PBB to support 1:1 protection switching between the two tunnels forming part of 1:1 protection switching mechanism. In PBB-TE a tunnel is identified by three identifiers (source backbone MAC address, destination backbone MAC address and backbone VLAN ID). A PBB-TE tunnel is provisioned end-to-end to transport data frames entering the BEBs. PBB-TE supports only 1:1 protection switching. In the FIG. 2 (as shown) two PBB-TE tunnels (work and protect). Upon failure of work, the traffic entering the BEBs are re-directed onto protect path. In PBB-TE tunnels terminate on the same BEBs, one on each point of the end-to-end transport. A work tunnel cannot be protected if end of the protect tunnel terminates on at least one different BEB. PBB-TE also supports P2MP service where there is one root and many leaves. Each leaf can communicate with the root and root can communicate with at least one leaf. If a root fails then there is failure of the P2MP service. PBB-TE does not have a mechanism to protect failure of root in P2MP service. Though, PBB-TE supports tunnel protection by switching from work to protect, the same mechanism cannot be extended to protect failure of roots in MRP2MP.
Therefore, to overcome the above restrictions it would be desirable to have a method and system to perform protecting of roots in a MRP2MP communication network.